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The first development of human factors engineering 
requirements for application to ground task design for a 

NASA flight program 


ABSTRACT 

The National Aeronautics and Space Administration has 
long applied standards-derived human engineering 
requirements to the development of hardware and 
software for use by astronauts while in flight. The most 
important source of these requirements has been NASA- 
STD-3000. While there have been several ground 
systems human engineering requirements documents, 
none has been applicable to the flight system as 
handled at NASA’s launch facility at Kennedy Space 
Center. At the time of the development of previous 
human launch systems, there were other considerations 
that were deemed more important than developing 
worksites for ground crews; e.g., hardware development 
schedule and vehicle performance. However, 
experience with these systems has shown that failure to 
design for ground tasks has resulted in launch schedule 
delays, ground operations that are more costly than they 
might be, and threats to flight safety. As the Agency 
begins the development of new systems to return 
humans to the moon, the new Constellation Program is 
addressing this issue with a new set of human 
engineering requirements. Among these requirements 
is a subset that will apply to the design of the flight 
components and that is intended to assure ground crew 
success in vehicle assembly and maintenance tasks. 
These requirements address worksite design for 
usability and for ground crew safety. 

INTRODUCTION 

The National Aeronautics and Space Administration 
(NASA) has long employed human factors requirements 
for development of flight systems. NASA-STD-3000 1 
was developed in the 1980s and has been applied to 
NASA human flight programs through a program-owned 
requirements document. The program chose those 
requirements in the standard that were applicable to 
programmatic missions and placed them into the 
requirements document, tailoring them if required to the 
specific application. For example, the International 
Space Station Program created SSP 50005 to be its 
human factors design specification 2 . Projects within the 
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program then used the program specification as a 
source of requirements for the lower-tier system 
specifications. NASA-STD-3000 does not include 
human factors design requirements for ground tasks, 
and therefore, programs have not been required to 
develop human factors requirements for ground crew 
tasks. Ground systems have applied human factors 
requirements to some systems, but this application has 
been sporadic, and these have not been based on 
programmatic direction. As a result, there has been 
inconsistent use and interpretation. Very importantly, 
requirements for worksite design and ground crew safety 
have never been applicable to flight systems. The result 
has been that ground crews have had to develop 
complicated strategies for accomplishment of ground 
assembly and maintenance of flight systems. This has 
increased the risk of human error and added time to 
these tasks, both for task completion and for 
assessment of successful task completion (i.e., quality 
assurance, QA). This has resulted in much higher 
expense for ground processes of flight systems than 
would be the case if human factors had been designed 
in. 

The Constellation Program (the execution program for 
the Exploration Vision) has accepted the responsibility, 
imposed by the NASA Administrator, to find ways to 
reduce ground operations costs. One of the ways the 
Program is doing this is through the application of 
human factors design requirements to flight systems. 

The intent is to design these systems to be more reliably 
and easily worked on while under NASA control. 


HISTORY OF HUMAN FACTORS DESIGN 
STANDARDS AT NASA 

NASA-STD-3000, developed as an Agency standard, 
was derived, in large part, from a Center-level standard 
developed by the Marshall Space Flight Center (MSFC) 
in the 1970s. The Man/System Requirements for 
Weightless Environments 3 was created by MSFC based 
on experience with Skylab, which was the first NASA 



project with large interior vehicle volumes and planned 
tasks requiring worksite design. This document was, in 
turn, derived from an earlier MSFC standard, developed 
for ground work tasks at MSFC during Saturn Launch 
Vehicle assembly, the Standard Human Engineering 
Design Criteria 4 . Finally, this document was inspired by 
the efforts of the developers of MIL-STD-1472, which 
was being created at the same time 5 . 

DEVELOPMENT OF REQUIREMENTS FOR 
CONSTELLATION 

PROCESS 

A driving goal for Exploration, as defined in the Vision for 
Space Exploration and in various speeches by the 
NASA Administrator is to reduce launch costs by 
reducing ground operations costs by an order of 
magnitude over the costs incurred by the Shuttle 6 7 . The 
Space Shuttle is the most capable space vehicle yet 
created, but its flight robustness comes at the cost of 
ground processing investment. Given the reality that 
NASA must survive with stable funding, there is no 
reasonable way to continue to fly the Shuttle, investing 
as much as the United States does in these flights, and 
to move beyond Earth Orbit at the same time, so the 
concept of a new launch vehicle to replace the Shuttle 
was introduced. This new vehicle will be simpler than the 
Shuttle, and it therefore will be inherently less expensive 
to operate. In addition, programmatic requirements 
have been developed to reduce ground operations costs 
as much as is feasible. Among these is a set of 
requirements included as a chapter in the programmatic 
human engineering requirements document, the Human 
Systems Integration Requirements 8 (HSIR). This set 
comprises a chapter in the HSIR, and the requirements 
apply to the design of the flight systems. That is, they 
are applied to the vehicle to be flown and control 
worksite design for those human tasks that NASA or its 
contractors will have to perform on the vehicle, primarily 
at KSC. 

RATIONALE AND APPLICABILITY 

In general, NASA does not concern itself with processes 
in a contractor’s facility, except where those processes 
affect flight performance. Thus, the Agency imposes 
manufacturing standards and “best-practices” direction 
for welding, soldering, machining, and the like. It does 
not generally direct a manufacturer to design worksites 
for hardware manufacture to accommodate a range of 
worker sizes and so forth. This is under the purview of 
the manufacturer, in the belief that manufacturing 
companies will develop assembly efficiencies that suit 
their schedules and corporate goals. The manufacturer 
accepts responsibility for decisions about how to put the 
pieces together efficiently and safely. On the other 
hand, assembly of launch vehicles from components 
delivered by these manufacturers is the responsibility of 
NASA. After these components {e.g., External Tanks, 
Solid Rocket Boosters, and Orbiters, in the Space 
Shuttle Program) arrive at the launch integration site 


(KSC), they are owned by NASA and are no longer the 
responsibility of the manufacturers. Similarly, the 
Agency and its operations contractors will be 
responsible for the assembly of the launch stack for 
Constellation, and it is the interfaces which NASA will 
have to interact with that the requirements apply to. 

Considerable experience with ground tasks associated 
with the processing of space launch systems leads to 
the conclusion that failure to design systems for ground 
crew interfaces adds to processing time and introduces 
risk 9 ' 10 . This is because failure to design for human 
tasks results in tasks that are challenging for ground 
crews to accomplish. Operational workarounds must be 
implemented at the launch assembly site. At a 
minimum, these workarounds add complexity by 
requiring more personnel than might optimally have 
been needed, which results in increased operational 
costs. More worrisome, some tasks become inherently 
risky, either through added complexity or by placing 
demands on ground personnel which result in increased 
error. For example, there are numerous task sites within 
the Space Shuttle Orbiter which provide insufficient work 
envelope; this often results in a worker mating 
connectors or driving bolts overhead, or in some other 
awkward position, and in the blind. In such cases, the 
forces required for task completion may exceed the 
normal range of capabilities. This results in special 
selection of technicians to perform the task: individuals 
with long reach, possibly thin body, and high shoulder, 
arm, and wrist strength. Specific workarounds such as 
this slow processing operations, while the individual 
capable of the task is scheduled into the workflow. Such 
specialized scheduling will invariably lead to delays and 
therefore add to costs. Moreover, the inspection of the 
task by QA personnel may not really be feasible, since 
another individual with the same anthropometric 
characteristics will be difficult to locate within the QA 
staff. It is thus possible that an improperly secured 
connection or insufficiently torqued bolt will result in a 
failure during the launch phase, when the vehicle is 
shaken violently. The failure could be that the connector 
demates, resulting in an electronics (power, computer, 
communication) failure. In the case of the improperly 
tightened bolt, the hardware could come loose, 
damaging or destroying it and its function, and possibly 
damaging other hardware nearby. Previous NASA 
launch system design activities have not imposed 
human factors engineering requirements, primarily for 
two reasons. The focus of the design has been on the 
flight performance of the vehicle: how well it 

accomplishes its primary objective of getting crews and 
payloads to orbit. Secondly, the issues mentioned 
above of operational costs and risks incurred were not 
fully appreciated. In fact, it is primarily through the 
Space Shuttle Program that we have learned about 
these issues. During Mercury, Gemini, and Apollo, the 
costs were simply not the driving concern; very large 
numbers of technicians were employed to meet the 
schedule of the ambitious goal of reaching the moon in 
the decade. Such numbers simply swamped the issues 
of finding anthropometrically-appropriate workers. A 



high proportion of the large costs for Shuttle ground 
processing is due to the number of personnel required, 
and this provides an opportunity for the Constellation 
Program: reduction of ground processing workforce will 
result in direct reduction of ground operations costs, an 
Agency objective 11 . 

DEVELOPMENT OF THE REQUIREMENTS IN THE 
PROGRAM 

In the summer and fall of 2006, the Agency was in the 
process of developing the requirements set for all 
aspects of the Constellation Program. The process 
began with the definition of missions, and performance 
and design requirements were identified that would 
support the needs, goals, and objectives associated with 
these missions. The missions identified included 
support to the International Space Station (ISS), in the 
form of crew changeout and supply delivery, as well as 
definition of the types of lunar missions to be 
accomplished. Both types of missions call for launch 
capabilities similar to those of the 1960s. While the 
launch rate itself will not be as high as during that 
decade, there are requirements for two launches within 
ninety minutes and for rapid assembly of the launch 
stack upon arrival of components at KSC. These 
capabilities are driven by and correlated to the launch 
“availability,” which is a measure of ease of assembly 
and of the reliability of the launch system 12 . In support of 
these programmatic goals, the authors proposed that 
human engineering requirements be developed for 
ground human tasks associated with the assembly of the 
vehicle and any maintenance activities that might be 
required to assure the desired launch availability. The 
program readily declared that such requirements were 
needed to meet these goals and tasked the authors to 
develop them. One of us (DS) had considerable 
experience in identifying ground task requirements for 
flight systems, and the other two had experience with 
development of requirements for spaceflight and for 
ground systems 9 . 

STRUCTURE AND NATURE OF THE 
REQUIREMENTS 

The primary objective of the team was to develop a 
basic set of requirements that could provide projects 
within the program a starting point from which to derive a 
set of requirements appropriate to that project. This was 
driven by two considerations: there was little time to 
invest in development of a complete set, and the 
philosophical approach was that there should be latitude 
for interpretation and trading of design requirements 
against other considerations. The requirements were 
not part of the NASA flight human factors requirements 
set found in NASA-STD-3000, as previously mentioned. 
This made the addition to the HSIR a rush job, and 
examples were needed. The earlier NASA standards 
documents which did include ground design 
requirements were somewhat dated, but more 
importantly, they focused on manufacturing processes 
and facility design to a large extent. This set of 


requirements was conceived and commissioned to 
influence design for vehicle assembly and those 
maintenance tasks to be performed only at KSC, as 
preciously mentioned. MIL-STD-1472F was considered 
to be a more up-to-date starting point, and it was in use 
at KSC for design of ground systems. It was culled for 
requirements which might be applicable or adaptable to 
space flight systems. The other consideration, that there 
be latitude for tailoring for specific projects, enabled 
selection of generic requirements. In general, human 
factors engineering requirements for spaceflight 
application are “hard” requirements, meaning they must 
be strictly adhered to. This is because many tasks 
during a mission must be done correctly “first time, every 
time.” Task error can have direct and immediate impact 
on crew safety and mission success. On the other hand, 
ground task design can reasonably be considered a 
tradable commodity, when considering overall vehicle 
performance. Thus, if the imposition of human factors 
engineering requirements for ground tasks resulted in 
significant increases in weight, the sense among the 
team was that projects should be allowed some leeway 
in the imposition of these requirements, if suitable 
workarounds can be planned that could be 
demonstrated to result in a safe design. Such tailoring 
of requirements is achieved through programmatic 
concurrence, to assure the overall program objectives of 
launch availability and mission capability are met. It was 
with this thinking that the selection of a small generic set 
of requirements was made. The process was fairly 
quick, from a requirements development standpoint, 
because this approach did not demand that a great deal 
of supporting data be provided. The requirements 
addressed primarily the basic demands of worksite 
development: reach envelopes, body and work 

envelopes, tool envelopes, and visual envelopes. In 
addition to these, some specific requirements were 
added, based on experience from ground processing 
personnel at KSC. 

EXAMPLES 

The Constellation Program adopted a policy for all 
requirements documents that each requirement be 
matched to a rationale statement and a verification 
requirement. The rationale shows up in the document 
immediately under the requirement and is intended to 
explain the need for the requirement and, if necessary, 
the thought process behind it, to aid in interpretation. 
The verification requirement states how the design 
requirement is to be verified; this provides additional 
information to the hardware developer of the intent and 
helps assure the requirement is well-written. 

Example of a general requirement, rationale, and 

verification requirement: 3. 9. 6. 7 Work Envelope 

Volumes [HS10002] The system shall provide work 

envelope volumes needed to perform 

corrective and preventive maintenance tasks, as well as 

assembly and other launch site 

processing tasks. 

Rationale: The flight system components/subsystems 



(Ares I stages, Orion Service Module [SM] and Crew 
Module [CM], e.g.,) must be assembled by the ground 
crew with sufficient work envelope to accomplish tasks. 
Many of these tasks will constitute mating of 
components (bolts, connectors, etc.) across the interface 
between Elements (Ares I 1st: 2nd stage, e.g.,) or 
between systems (Ares I: Orion). These envelopes will 
therefore be identified by Vehicle-level task analyses 
and documented in Interface Control Documents (ICDs). 
Corrective and preventive maintenance tasks that are 
accomplished fully within one Element may be analyzed 
at the Element level. Guidelines for envelope definition 
are found in FAA-HF-STD- 001 Section 14.1. Sufficient 
envelope is defined by task analyst using this document 
and based on anthropometric requirements and task 
definition. The envelope definition will be concurred with 
by Level II. 

4. 9. 6. 7 Work Envelope Volumes 

[HS1 0002V] Assembly and maintenance work envelope 
volumes shall be verified by analysis. The analysis shall 
consist of task and worksite analysis. The Vehicle 
Assembly Task Analysis and the Vehicle Maintenance 
Task Analysis shall be applied to determine task 
assumptions and constraints (e.g., SCAPE suit), and the 
worksite analysis shall account for constraints. Analysis 
shall account for the anthropometric range as applicable, 
the task, and the environmental constraints. The 
verification shall be considered successful when the 
analysis shows that the tasks have the needed work 
envelope volumes. 

Rationale: No further Rationale required. 

Example of a requirement that is based on lessons- 
learned from experience at KSC : 3. 9. 7. 7. 7 Protrusion 
Label/Support [HS10043] The system shall design all 
accessible protrusions that could be inadvertently used 
as handles, steps, hand rails, or mobility aids either to 
support the weight of personnel or clearly labeled as 
keep-out zone. 

Rationale: Historical experience with Shuttle and Station 
has shown that it is important to make it clear which 
parts of a vehicle may not be used as handles, steps, or 
handrails so that as ground and flight crews move 
around the vehicle they do not inadvertently damage 
delicate portions. Preference should be given to 
designing to support in areas where ground and flight 
crews will travel frequently. 

4. 9. 7. 7. 7 Protrusion Label/Support 

[HS1 0043V] Protrusions that could be used as handles, 
steps, or hand rails shall be verified by analysis. The 
analysis shall determine which protrusions could be 
inadvertently used for handles, steps, hand rails, or 
mobility aids. The verification shall be considered 
successful when the analysis shows that the identified 
protrusions accessible to the ground and flight crews 
can support the weight of personnel or are clearly 
labeled as a Keep Out Zone. 

Rationale: No further Rationale required. 


ISSUES AND CHALLENGES 


Some requirements have presented challenges, but not 
all of these have been technical. Verifiability has been a 
significant concern. For example, the anthropometry 
requirement, as originally stated, said that “5 th to 95 th 
percentile” workers would be accommodated. This is a 
common range of workers to be designed for, but, as 
anyone who has tried to apply it will understand, its use 
is not straightforward. The question, familiar to all 
worksite designers, is, “Which anthropometric dimension 
needs to fall within this range?” Often, designers are 
encouraged to select those dimensions which are most 
critical for the task being designed for. In an attempt to 
simplify the requirement, the authors added the phrase, 
“for stature,” but even this is unsatisfactory. Moreover, 
the requirement did not specify a database on which to 
draw in order to develop worksite design. It was our 
intent to have hardware developers (manufacturers) 
inform the Agency how they had arrived at the 
anthropometries they used in the design. This was 
considered unsatisfactory, for two perfectly reasonable 
reasons: it required the developer to expend time and 
effort (and hence, money) to decide on a database, and 
different developers could decide to use different 
databases. This could result in inconsistency of design 
and potential worksite design problems at the interfaces 
between hardware delivered by different developers. 
Thus, the Upper (second) Stage of the Ares I launch 
vehicle could select a different dataset than the Orion 
crewed vehicle, and integration problems could arise 
when these components are mated at Kennedy Space 
Center. The most recent version of the HSIR still does 
not specify the applicable database, but the author’s 
proposal is to simply use the human modeling tool as 
the standard for anthropometry. The Constellation 
Program has selected a CAD and simulation system 
which includes a human model for design and analysis, 
and this model is scalable; the position is to use the 
anthropometries designed into the model. The 
verification would then be straightforward: use of the 
human model to demonstrate task feasibility for the 
range inherent in the model would allow verification 
closure. This would support one of the basic concepts 
behind inclusion of anthropometry in design 
considerations: it gets the worksite design “in the 

ballpark” for the workers who must perform tasks. All 
qualified worksite designers recognize that no design will 
accommodate all potential workers; the intent of the 
imposition of such a requirement is to assure that worker 
sizes have been considered in the design, with the 
understanding that some workers will not be able to 
perform some tasks. 


Another requirement which has been difficult to establish 
is one calling for a defined tool set ([HS10028] The 
system shall be assembled and maintained using only 
those tools identified in the Launch Site Task Tool List 
(TBD-006-050).). While not uniquely a human factors 
design requirement (it supports logistics planning, as 
well), it is intended to allow a worksite designer to 
understand the tools that might be selected for a task, 



enabling assessment of tool envelopes. It was created 
with the idea that a tool list already exists for Shuttle, 
and that this could be transferred to Constellation. A 
complete list has been difficult to acquire, however. This 
appears to be related to contractual issues; the KSC 
contractor which manages tools is not obligated to 
provide the list to Constellation. While this should 
ultimately be resolvable, the designers are currently 
without a tool set. 


CONCLUSION 

One of the goals of the Exploration Vision is a reduction 
of costs associated with launch processing. The primary 
goals of Exploration are, of course, discovery of the 
nature of other bodies in the solar system and 
establishing permanent human presence there. 
Improving ground processing is thus not a primary goal, 
but it is an enabling one. The idea is that NASA budgets 
are unlikely to increase in the foreseeable future, and 
the Agency must learn to reduce ground operations 
costs in order to have a greater proportion of its budget 
go to space applications. One of the paths Constellation 
is using to achieve this goal is the application of human 
factors requirements to the design of worksites for 
launch vehicle assembly and maintenance. These 
requirements have gone into programmatic 
documentation as additions to the flight crew human 
factors requirements in the HSIR and are applicable to 
the flight systems only. 
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